Just for fun:

Binary size when including Kyoto, building the aarch64 binary on macOS using the release-smaller profile (libbdkffi.dylib): 9.7MB
Binary size without Kyoto, building the aarch64 binary on macOS using the release-smaller profile (libbdkffi.dylib): 8.6MB

Not bad at all for what is likely to be one of the most popular clients one day.

Awesome thank you for checking that out. Props to rust-bitcoin and tokio for keeping things tidy.

Objects cannot currently be used in enum variant data

You can imagine my disappointment with this error message after hacking on this PR again. I'm trying to express the new Event<K> from bdk_kyoto but it returns objects like Update (FullScanResult) as a variant. We can return more primitive types as variants, but then we can't express the Update. It doesn't make sense to express an event as anything else than an enum, as only one variant is used at a time to express the event.

It's been so long but maybe that is what I had in mind with the callback interface in the first place lol. Open to new ideas, but until we can return objects from enum variants I think we may have to stick with callbacks...

I consider this ready for review now. Some updates, I added live tests for android, JVM, swift, and python. Users now have to build a Peer with an IpAddress if they have a company or personal node they want to connect to. NodeMessageHandler is renamed to NodeEventHandler, which reflects a bit more what is happening. Some open questions I have:

Do we really need a separate live test in android when the JVM one exists? It's basically the exact same code and it would likely just increase the maintenance burden for no real benefit IMO.

Should I add docstrings? I think so, but I wanted to confirm

To answer your questions @rustaceanrob:

1. No I don't think we need a live test on Android if we have one on JVM (moreso because the Android emulators don't currently work in the CI!)
2. Yes let's add docstrings.

Awesome! I'll try to review this again next week.

I got it working on the Android example wallet! So far so good. I'll take a closer look at the code before giving the final ACK.

My first little API-related comment is that the NodeEventHandler doesn't have an unique event for a new block being mined but that's a significant event from the point of view of the user, particularly because they loose mempool information when using Kyoto (if blocks pass and the transaction they expect doesn't get mined they need to look into it).

At the moment this is what I do to pull the new blocks out of the events:

override fun dialog(dialog: String) {
    if (dialog.contains("peer height")) {
        val height = dialog.split("peer height: ")[1].split(" ")[0]
        triggerSnackbar("New block mined: $height")
    }
}

Which is basically a custom parsing of the string just to get what I need. I wonder if a newBlock() method on the interface would be cleaner.

Just to showcase my use of it, here is the simple version of the idea, where a snackbar shows when new blocks are mined:

The best known peer height is found when connecting to a peer, but our height may not yet match theirs yet. The Synced event is emitted every time we sync to their height, which includes when they advertise a new block to us. In effect, I believe the Synced event is more accurate as to what height the client is synced to. However, I did add a recent Progress event that does contain the best known height of remote peers, so the user has an idea of how many filters and filter headers must be downloaded until synced. I will add that in the next kyoto and bdk_kyoto releases and update this PR along with some other improvements.

For reference, I believe you can achieve the same effect in terms of the client height by using NodeEventHandler::synced and updating the toast bar

Oh sweet yes I had not looked at all the methods carefully enough. It was easy to update the app to use that instead. 👍

Small note: the Android library is missing a dependency on the kotlinx-coroutine-core library.

implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.8.1")

Added to bdk-android/lib/build-gradle.kts. Not sure if that is correct

With the cut of the release/1.1 branch, I don't think we'll be merging anything else that'll make it in before the big release. If we end up needing to add anything to the release, we'll merge those commits right on the release branch and cherry-pick on master if needed.

This means master is free to keep going at its own pace and I think this PR is ready to merge (again it will not make it into the 1.1 but rather in 1.2).

No real rush, but also I feel like @rustaceanrob has been really patient and rebasing every few days... I have this working well in my variant/kyoto app (which needs a big rebase on the esplora variant which has added a bunch of cleanups and features, but works well nonetheless!).

@reez what do you say? Have you had a chance to test it out a bit?
@rustaceanrob is this a version good to merge? Or are you expecting newer/better features in the next few days/weeks and would rather polish those up first?

I can rebase this soon and I think it's ready to go. I would prefer to do follow-up patches for anything additional

edit: Rebased

ACK d154117.